本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

一位住戶拿著鑰匙走到管理室，問師父能不能明天幫忙帶修繕師傅上樓，開門讓對方進去工作。他說自己臨時要出門，時間不會太久。

師父沒有接過鑰匙，先問來的是哪家廠商、住戶是否有人在場，再說這項安排需要向總幹事確認，不能只口頭交代就代為進屋。住戶留下聯絡方式，說那麻煩確認後通知他。

我等他離開，問師父：「順便幫一下，不是更容易讓住戶滿意嗎？」

師父回答：「要先知道幫的是哪一件事。誰帶人上去、誰開門、做完怎麼確認，不能只有一句順便。」

客戶願意付費，也要先拆開需求

我把問題換到新創：「那客戶願意付錢請你加功能呢？公司還小，看到收入總不能一直挑吧。」

師父說，當然要把收入算進去。他拿 AI 客服草稿工具舉例，假設一個客戶希望接上自己的訂單系統，而且願意支付導入費用。團隊就要先知道，要做的是大家可能都會用到的串接能力，還是只為這一家客戶處理特殊流程。

兩種工作都可能值得接，但後續安排不同。共用能力需要考慮其他客戶如何使用；一次性的資料轉換，可以界定輸入、輸出和交付條件；若承諾長期維護客戶的專屬流程，就得把後續人力也算進去。

我問：「那做成設定選項，不就能兩邊都顧到？」

師父說，有些差異適合設定，有些差異牽涉完全不同的流程。把所有特殊要求都藏進設定，產品可能變得很難測試，也沒有人知道哪些組合真的被支援。應該先理解共通點，再決定如何設計。

今天收到的錢，要一起算明年的工作

師父在空白紙上寫下幾個項目：開發、測試、導入、後續修改、故障支援。我說前面幾項報價時多少會算，後面的比較難估。

師父回答，難估也要知道自己答應了什麼。假設對方的訂單系統改版，串接是否必須免費跟著改？如果週末資料進不來，有沒有人需要立即處理？這些條件會決定同一筆導入費到底是在支付哪些工作。

我追問：「可是早期客戶可能就是要你多配合一點，才願意買。」

師父說，可以用配合換取有價值的機會，例如取得實際流程的理解、建立能重複使用的能力，或得到一筆對公司有幫助的收入。但交換的內容要清楚，也要承認它會占用原本的產品開發時間。

如果同時為三家客戶維護三套完全不同的流程，就得看團隊是否有能力承擔。不能在每一筆生意裡都說這次只是例外，加起來卻占滿所有人的工作。

我說：「那聽起來，早期公司最好都不要客製。」

師父搖頭。他說，往往某項客製化正好揭露一群客戶都有的問題，值得讓產品往那裡發展。
或者公司當下需要現金，而團隊能清楚界定一次性交付，接案就是合理的安排。重點是自己知道在做哪種生意，以及下一階段準備怎麼走。

決定要接，就把範圍和取捨說出來

我問師父：「如果是你，會怎麼把這單拿進團隊討論？」

師父說，先把客戶需要完成的流程說明，再列出哪些能用現有能力處理、哪些需要新增，以及誰會負責後續。接著比較這筆收入、可能帶來的共用價值，和因此延後的其他工作。

他舉了一個假設決定：先接一次性的歷史資料轉換，產出符合現有產品格式的檔案；長期自動同步另外評估。這樣客戶可以先導入，團隊也不會在還不了解系統時，承諾永久維護一條串接。

我追問：「客戶如果說，沒有自動同步就不買呢？」

師父說，那就是需要重新衡量的條件。可以調整價格、時程和支援內容，也可能最後談不成。拒絕一筆生意有代價，接受一個長期做不來的承諾也有代價，兩個都應該放在討論裡。

談到這裡，林總幹事回覆了住戶剛才的問題。這次請住戶自行安排能到場的人，管理室協助正常的廠商來訪登記，不代替住戶進屋帶看。師父把回覆和通知結果記下，確認鑰匙仍由住戶保管。

我問：「所以這次能幫忙的部分，就是來訪登記。」

師父說是，處理範圍確認了，就照著做。住戶如果還需要其他安排，也知道要另外找誰協調。

回到產品，客製需求要一起評估收入、共用價值和長期維護責任。決定接的時候，把承諾寫到能執行的程度；決定不接，也應該知道自己放棄了什麼。